searcher: fix cache size env vars rendering 0 for non-Gi storageSize - #948

Fixes the issue for impacted customers without requiring them to change their deployment, beyond upgrading.

Problem

SEARCHER_CACHE_SIZE_MB and SYMBOLS_CACHE_SIZE_MB were derived with trimSuffix "Gi" .Values.searcher.storageSize | mul 450. Any other valid PVC size (150G, 1Ti, 500000M) left a non-numeric string that sprig cast to 0, so both env vars rendered "0".

searcher treats an explicit 0 as "never evict" (an unset variable auto-sizes instead), so both caches grew unbounded until the PVC filled and the pod failed to start:

failed to setup TMPDIR: mkdir /mnt/cache/searcher-0/.searcher.tmp/tmpfriend-...: no space left on device

Reported by a customer with searcher.storageSize: 150G after upgrading 6.5.0 → 7.2.0. The template has behaved this way since v6.4 (#677), so the disk had been filling for months; it was only noticed in the logs after the upgrade.

Fix

• Extracted the Kubernetes quantity parser that sourcegraph.redis.maxmemory already had into a shared sourcegraph.quantityBytes helper in templates/_helpers.tpl. Accepts any quantity suffix (k/M/G/T/P/E, their i binary forms, fractional values, suffixless bytes).
• New sourcegraph.searcher.cacheSizeMB helper in templates/_helpers/_searcherCacheSize.tpl uses it to compute floor(bytes / 1e6) * 45 / 100, the same arithmetic searcher uses when it auto-sizes from the volume.
• The render fails, with a pointer to searcher.autoCacheSize=true, when the value is unparseable or so small the result would be 0 (anything under 3M). Silently disabling eviction is no longer possible.
• Both env blocks in searcher.StatefulSet.yaml call the helper. values.yaml comment, README (helm-docs), CHANGELOG, and a new searcherCacheSize_test.yaml suite.

Behaviour change for existing deployments

Binary units are now converted exactly instead of being treated as decimal, so every Gi deployment renders a slightly higher value and searcher pods restart on upgrade. The default 26Gi goes from 11700 to 12562; 100Gi from 45000 to 48318. These match what searcher's auto-sizing would pick for the same disk.

Two caches at 45% each is 90% of the nominal PVC. The old Gi × 450 math happened to leave more slack (2 × 11700 MB is 84% of 26Gi). searcher's auto mode uses 90% of the mounted filesystem, which is a few percent smaller than the PVC request, and TMPDIR shares the volume. Operators who want more headroom should enable searcher.autoCacheSize.

Verification

./scripts/helm-docs.sh             # no diff
helm unittest charts/sourcegraph   # 32 suites, 195 tests passed
helm lint charts/sourcegraph